According to statistics, requirements management is identified as a major source of error to failed IT-projects. Moreover communication is identified as a factor affecting the require-ments management and can lead to deficiencies in the requirements. The requirements analyst is responsible for managing the requirements from the different stakeholders, act as a com-munication accommodator and to translate abstract requirements expressed by users to more specific requirements that developers can implement. The purpose of this thesis is to study the role of the requirements analyst to investigate the problems that may arise in working with requirements management.  To achieve the purpose we have performed a requirements management process in which we ourselves took the role as the requirements analysts. The requirements management process consisted of three phases: gather requirements, document requirements and validate require-ments.

The result from Requirements Engineering is a Requirements Specification. Characteristics of a good Requirements Specification are unambiguity, completeness, verifiability, consistency, modifiability, traceability, correctness and ranked for importance and/or stability.This work defines these quality attributes and answers the questions how to reach these attributes and the diffuculties which exist in this area.This work should be read to get an overwiew of the area Requirements Engineering and Requirements Specification..

Denna rapport avser att undersöka för- och nackdelar med att utveckla ett för ändamålet specialanpassat system eller utnyttja de standardsystem, som i det aktuella fallet tryckerikoncernen JMS redan äger och använder. Genom en mer noggrann definiering av ickefunktionella krav på bland annat användbarhet har en specialanpassad prototyp framställts. I projektet användes metoder för kravinsamling som ledde till en kravspecifikation och i sin tur slutade med en färdig prototyp. Prototypen jämfördes med två standardsystem genom användartester och intervjuer. Prototypen visade sig leva upp till de krav som upptäcktes.

Computer use at work has risen considerably over the past fifteen years and is currently a relatively common phenomenon when 76 percent of women and 72 percent of men using the computer in their daily work (SCB Arbetsmiljörapport 2009).According to Gulliksen and Göransson (2009), Sweden is one of the countries which are more advanced in the procurement of computer systems at work. He means that Sweden has unique opportunities and conditions for user participation in the development of computer systems, when the user has the right to influence their working environment through a law in the Work Environment Act. The paper examines the importance of user involvement in system development and the Swedish company's approach and experience of user involvement. To highlight and explore the importance of user involvement, there has been a case study in which users have been representative of the development process. The case study has been conducted on a case company where the system IST analys was in need of a new interface.

The starting point of this paper has to do with rapid changes within the information technology and the need for agile and fast systems. The primary goal is to investigate what happens with recordkeeping practices in agile environments like service oriented architecture (SOA). It is in the possible transfer between IT architecture and digital archive the area of this paper resides. The paper relates to the Records Continuum model by which records will be considered historical and active at the time of creation. In the Records Continuum model recordkeeping practices and archival requirements will have to be taken into account at the time of creation.This paper concerns SOA from the perspective of Archival and Information science.

 Extra high requirements are made on all systems in health care that they are functional and usable,´something, however, that is not always the case. At Emergency Admissions at Sahlgrenska University´Hospital many systems are in use at the same time and it happens that much overhead is caused by having to fill in the same information in different places. In addition, data that is gathered is to a large extent saved in free text format, which means that it cannot be used in a larger context such as research, quality control or for decision support. Data is saved in the patient file only for the treatment process of the individual patient.A data collecting system with decision support functionality could be a first step towards reducing Emergency Admissions? costs and patients? waiting times by providing a structured method of data collection.

Prioritisation of software requirements is a critical part of the development of software. Whichrequirements and in which order they will be developed is one of the main tasks that requirementprioritisation supports.There are different ways that a requirement prioritisation can be used, for example alone or in agroup and with different methods.The purpose of this report is to map out how you can carry out a requirement prioritisation alonewith different types of prioritisation methods and how you solve the problems that can arise whenprioritisting requirements. This is done by documenting the use of three different types of methodsthat can be execute alone. The methods are "100-dollar test", "Ranking" and "Top-tenrequirements".To be able to prioritise requirements, you need to establish which requirements you shall prioritise.The paper retrieves this information by interviewing stakeholders in the system and analysing theresult of the interviews and the execution of the requirement prioritisation.Three problems arose during that work and I present solutions on these problems. The problemswere 1) equivalent requirements when using the "100-dollar test", 2) low differentiation gradebetween the prioritised requirements in the "100-dollar test" and 3) that the requirements that wereprioritised weren't classified before the prioritisation, which leads to inaccuracies in the resultingprioritisation.The solution to the problems that the paper presents is to increase the amount of distributable unitsin the "100-dollar test" to 1000 per requirement, suggestions of classes of the requirements andthe combination of the methods "100-dollar test" and "ranking" to bypass the equivalentrequirements.The report is written in Swedish.Nyckelord: GoTRIS, requirements retrieval, requirements analysis, Viktoria Swedish ICT,requirements prioritisation, requirements, 100-dollar test, ranking, top 10 requirements..

Requirements engineering is a widespread topic in the research field of informatics. However, there is little research regarding lack of requirements documentation and how it is perceived. The same applies for how requirements engineering in retrospect can be implemented. This is a debated issue on blogs and forums but it has not been reflected in the research area.Therefore, this study concerns research questions regarding how the developers, testers and requirements analyst experience the lack of requirements documentation and how requirements engineering in retrospect can be implemented.To answer these questions, data collection has been conducted through qualitative interviews with individuals affected by this problem in their everyday work.This study has provided an explanation of how the problem is perceived and what the consequences are, both direct and indirect. The impacts are divided into three categories and are presented as, emotional consequences, system implications and consequences regarding re source consumption.

Requirements engineering is a widespread topic in the research field of informatics. However, there is little research regarding lack of requirements documentation and how it is perceived. The same applies for how requirements engineering in retrospect can be implemented. This is a debated issue on blogs and forums but it has not been reflected in the research area.Therefore, this study concerns research questions regarding how the developers, testers and requirements analyst experience the lack of requirements documentation and how requirements engineering in retrospect can be implemented.To answer these questions, data collection has been conducted through qualitative interviews with individuals affected by this problem in their everyday work.This study has provided an explanation of how the problem is perceived and what the consequences are, both direct and indirect. The impacts are divided into three categories and are presented as, emotional consequences, system implications and consequences regarding re source consumption.

Requirements engineering is a widespread topic in the research field of informatics. However, there is little research regarding lack of requirements documentation and how it is perceived. The same applies for how requirements engineering in retrospect can be implemented. This is a debated issue on blogs and forums but it has not been reflected in the research area.Therefore, this study concerns research questions regarding how the developers, testers and requirements analyst experience the lack of requirements documentation and how requirements engineering in retrospect can be implemented.To answer these questions, data collection has been conducted through qualitative interviews with individuals affected by this problem in their everyday work.This study has provided an explanation of how the problem is perceived and what the consequences are, both direct and indirect. The impacts are divided into three categories and are presented as, emotional consequences, system implications and consequences regarding re source consumption.

Requirements engineering is a widespread topic in the research field of informatics. However, there is little research regarding lack of requirements documentation and how it is perceived. The same applies for how requirements engineering in retrospect can be implemented. This is a debated issue on blogs and forums but it has not been reflected in the research area.Therefore, this study concerns research questions regarding how the developers, testers and requirements analyst experience the lack of requirements documentation and how requirements engineering in retrospect can be implemented.To answer these questions, data collection has been conducted through qualitative interviews with individuals affected by this problem in their everyday work.This study has provided an explanation of how the problem is perceived and what the consequences are, both direct and indirect. The impacts are divided into three categories and are presented as, emotional consequences, system implications and consequences regarding re source consumption.

The building and plant sectors represent a large part of Sweden?s energy use. Putting energy requirements in public procurement as a tool for reducing energy consumption in the building and plant sectors is therefor an opportunity that operators can take advantage of. The aim of this thesis was to map the energy requirements in procurement that operators in the public sector use today in building and plant projects. The analysis was made with respect to if the energy requirements corresponded to the parts with large energy use in building and plant projects and also in which way energy requirements in procurement are written in the contract.

This study looked at two groups of adolescents aged 12-17 years who had participated in circus training. One group had some form of disability while the other had none. The study was carried out as a qualitative study with observations, interviews and a questionnaire used as methods of gathering data. A small part of the study was quantitative and an observation chart was used. The purpose was to examine the importance of teamwork, environmental factors and the necessary requirements during a learning situation.

The use of mobile devices has during the last years expanded and on the market you can see a huge amount of applications. The development of mobile applications differs from traditional systems development since mobility infers that mobile applications can be used in different technological and social contexts. Although previous research has recognized that mobility can present mobile application developers with certain challenges, empirical studies of how problems arise and how they can be handled has thus far been limited. In this study we focused on the requirements engineering process from a development view with the purpose of finding challenges emerging in the development process. The study is based on a qualitative case study that employed semi-structured interviews with both project managers and system developers active in the requirements process.

Requirements management is an important part of the software development process. The success of a project may depend on how this is handled. Even though several research studies indicates that more attention should be paid on non-functional requirements, the primary focus in practical projects still regards identifying functional requirements. Especially the prioritization of the non-functional requirements has been proven to be of great importance for the success of a project.This report investigates basics in agile requirements management involving opinions from experts from a software development company. This is done with help of existing literature and interviews with key actors involved in prioritization at the company.